home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-avt-rtp-01.txt < prev    next >
Encoding:
Text File  |  1993-06-07  |  47.3 KB  |  1,096 lines
  1.  
  2.  
  3. Internet Engineering Task Force                     Audio-Video Transport WG
  4. INTERNET-DRAFT                                      H. Schulzrinne/S. Casner
  5.                                                                     AT&T/ISI
  6.                                                                  May 6, 1993
  7.                                                           Expires:  10/01/93
  8.  
  9.  
  10.               A Transport Protocol for Real-Time Applications
  11.  
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.  
  17. This document is an Internet Draft.   Internet Drafts are working  documents
  18. of the Internet Engineering  Task Force (IETF), its  Areas, and its  Working
  19. Groups.   Note that other  groups may also  distribute working documents  as
  20. Internet Drafts.
  21.  
  22. Internet Drafts  are draft  documents valid  for a  maximum of  six  months.
  23. Internet Drafts may be  updated, replaced, or  obsoleted by other  documents
  24. at any time.   It  is not appropriate  to use Internet  Drafts as  reference
  25. material or to  cite them other  than as  a ``working draft''  or ``work  in
  26. progress.''
  27.  
  28. Please check  the I-D  abstract  listing contained  in each  Internet  Draft
  29. directory to learn the current status of this or any other Internet Draft.
  30.  
  31. Distribution of this document is unlimited.
  32.  
  33.  
  34. Contents
  35.  
  36.  
  37. 1 Introduction                                                             2
  38.  
  39.  
  40. 2 Real-time Data Transfer Protocol -- RTP                                  4
  41.  
  42.   2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  43.  
  44.   2.2 RTP Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . 5
  45.  
  46. 3 Reverse Control                                                          8
  47.  
  48.  
  49. 4 Real Time Control Protocol --- RTCP                                      9
  50.  
  51.   4.1 Forward Control Options . . . . . . . . . . . . . . . . . . . . . . 10
  52.  
  53.  
  54. INTERNET-DRAFT                        RTP                        May 6, 1993
  55.  
  56. 5 Security Considerations                                                 15
  57.  
  58.  
  59. 6 RTP over network and transport protocols                                15
  60.  
  61.   6.1 Defaults  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
  62.  
  63.     6.1.1Framing  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
  64.  
  65.     6.1.2RTA option . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  66.  
  67.   6.2 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  68.  
  69.   6.3 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  70.  
  71.   6.4 ST-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  72.  
  73. A Implementation Notes                                                    17
  74.  
  75.  
  76. B Addresses of Authors                                                    18
  77.  
  78.  
  79.                                   Abstract
  80.  
  81.  
  82.      This  draft  describes  a protocol  called  RTP  suitable for  the
  83.     network  transport of  real-time  data,  such  as audio,  video  or
  84.     simulation data.    The  data transport  is enhanced  by  a control
  85.     protocol  designed to  provide minimal  control  and identification
  86.     functionality.  A reverse  control protocol provides mechanisms for
  87.     monitoring quality of service  and other content-specific requests.
  88.     This protocol is intended for experimental use.
  89.  
  90.  
  91. This specification is a product  of the Audio-Video Transport working  group
  92. within the Internet  Engineering Task  Force.   Comments  are solicited  and
  93. should be addressed to the  working group's mailing list at  rem-conf@es.net
  94. and/or the authors.
  95.  
  96.  
  97.  
  98. 1 Introduction
  99.  
  100.  
  101. This draft concisely specifies a real-time transport protocol.  A discussion
  102. of the design decisions can be found in the current version of the companion
  103. Internet draft draft-ietf-avt-issues.txt.   The transport protocol  provides
  104. end-to-end delivery services for  one or more f_l_o_w_s_  of data with  real-time
  105. characteristics, for example,  interactive audio  and video.    It does  n_o_t_
  106. guarantee delivery  or prevent  out-of-order delivery,  nor does  it  assume
  107. that the underlying network  is reliable and  delivers packets in  sequence.
  108.  
  109. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 2]
  110.  
  111.  
  112. INTERNET-DRAFT                        RTP                        May 6, 1993
  113.  
  114. [Note that the  sequence numbers  included in RTP  allow the  end system  to
  115. reconstruct the  sender's packet  sequence, but  sequence numbers  may  also
  116. be used  to determine  the  proper location  of  a packet,  for  example  in
  117. video decoding, without necessarily decoding packets  in sequence].  RTP  is
  118. designed to run on top of a variety of network and transport protocols,  for
  119. example, IP, ST-II or UDP.  [For most applications, RTP offers  insufficient
  120. demultiplexing to  run directly  on  IP.] RTP  transfers  data in  a  single
  121. direction, possibly to multiple destinations if supported by the  underlying
  122. network.   A mechanism  for indicating  a return  path for  control data  is
  123. provided.
  124.  
  125. While RTP is primarily  designed to satisfy  the needs of  multi-participant
  126. multimedia conferences, it  is not limited  to that particular  application.
  127. Storage of continuous data,  interactive distributed simulation and  control
  128. and measurement applications  may also find  RTP applicable.   Profiles  are
  129. used to instantiate certain  header fields and  options for particular  sets
  130. of applications.   A profile for audio  and video data may  be found in  the
  131. companion Internet draft draft-ietf-avt-profile.txt.
  132.  
  133. This document defines two packet formats and protocols:
  134.  
  135.  
  136.   o the  real-time  transport  protocol  (RTP)  for  exchanging  data   with
  137.     real-time properties.
  138.  
  139.   o the real-time  control protocol (RTCP)  for conveying information  about
  140.     the sites in an on-going  association.  RTCP information may be  ignored
  141.     without affecting the  ability to correctly  receive information.   RTCP
  142.     is used  for loosely  controlled conferences,  i.e., where  there is  no
  143.     explicit  admission control  and  set-up.    Its  functionality  may  be
  144.     subsumed by a conference control protocol (which is beyond the  scope of
  145.     this document).
  146.  
  147.  
  148. Control fields  (options) for  RTP and  RTCP share  the same  structure  and
  149. numbering space and are carried within the same packet.  Options may  appear
  150. in any  order, unless  specifically restricted  by the  option  description.
  151. [The position of some security options may have significance.]  Each  option
  152. consists of the final bit, the  option type designation, a one-octet  length
  153. field denoting the total number of  32-bit long words comprising the  option
  154. (including final  bit, type  and length),  and  finally any  option-specific
  155. data.  The last  option before the packet data  portion has the 'F'  (final)
  156. bit set to one, for all other options this field has a value of zero.
  157.  
  158. Fields within the fixed header and within options are aligned to the natural
  159. length of  the field,  i.e., 16-bit  words are  aligned  on even  addresses,
  160. 32-bit long words are aligned at addresses  divisible by four, etc.   Octets
  161. designated as padding  have the  value zero.    Options unknown  to the  RTP
  162. implementation or the application  are to be ignored.   Options with  option
  163. types having values  from 64 to  127 inclusive  are to be  used for  private
  164. extensions.  Fields designated as MBZ ('must be zero') must have a value  of
  165.  
  166.  
  167. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 3]
  168.  
  169.  
  170. INTERNET-DRAFT                        RTP                        May 6, 1993
  171.  
  172. binary zero and are to be ignored by the receiver.
  173.  
  174. All integer  fields  are  carried in  network  byte  order,  that  is,  most
  175. significant byte (octet)  first.   The  transmission order  is described  in
  176. detail in [1], Appendix A. Unless otherwise noted, constants are in  decimal
  177. (base 10).
  178.  
  179. Textual information is  encoded accorded to  the UTF-2 encoding  of the  ISO
  180. standard 10646 (Annex F) [2,3].  US-ASCII  is a subset of this encoding and
  181. requires no additional encoding.   The presence  of multi-byte encodings  is
  182. indicated by setting the  most significant bit to  a value of one.   A  byte
  183. with a binary value of zero may  be used as a string terminator for  padding
  184. purposes.
  185.  
  186.  
  187.  
  188. 2 Real-time Data Transfer Protocol -- RTP
  189.  
  190.  
  191. 2.1 Definitions
  192.  
  193.  
  194. A c_o_n_t_e_n_t_ s_o_u_r_c_e_ is the actual source of the data carried, for example,  the
  195. user and host that originally generated the audio data.
  196.  
  197. A s_y_n_c_h_r_o_n_i_z_a_t_i_o_n_ s_o_u_r_c_e_ is the combination  of one or more content  sources
  198. with its own timing.
  199.  
  200. A n_e_t_w_o_r_k_ s_o_u_r_c_e_ is the network-level origin of the RPDUs as seen by the end
  201. system.
  202.  
  203. An e_n_d_ s_y_s_t_e_m_ generates the content to  be used in RTP packets and  delivers
  204. the content of received RTP packets to the user application.  An end  system
  205. is a synchronization source.
  206.  
  207. An (RTP-level)  b_r_i_d_g_e_  receives  RTP  packets from  one  or  more  sources,
  208. combines them in some manner and then forwards  a new RTP packet.  A  bridge
  209. may change the encoding.   A bridge always changes the timing  relationship,
  210. introducing a new  time scale.   Bridges are  synchronization sources,  with
  211. each of the sources whose packets were combined into an outgoing RTP  packet
  212. as the  content  sources  for that  outgoing  packet.    Audio  bridges  and
  213. media converters are examples  of bridges.   Example:  assume SMITH@FOO  and
  214. JONES@BAR are using a bridge to  translate their audio from one encoding  to
  215. another.  The bridge mixes audio  packets from Smith and Jones together  and
  216. forwards the mixed packets.   If, say, Smith  was talking, she is  indicated
  217. as the  content source  of the  outgoing packet,  allowing the  receiver  to
  218. properly display the current speaker rather than just the bridge that  mixed
  219. the audio.  For  an end system receiving RTP  packets from that bridge,  the
  220. bridge is the  synchronization source  and Smith the  content source.    The
  221. RTP-level bridges  described in  this  document are  unrelated to  the  data
  222. link-layer bridges found in  local area networks.   If there is  possibility
  223.  
  224.  
  225. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 4]
  226.  
  227.  
  228. INTERNET-DRAFT                        RTP                        May 6, 1993
  229.  
  230. for confusion,  the term  'RTP-level  bridge' should  be used.    [The  name
  231. 'bridge' follows common telecommunication usage.]
  232.  
  233. An (RTP-level) t_r_a_n_s_l_a_t_o_r_ does not alter the timing of packets.  Examples of
  234. its use include encoding conversion  without mixing or retiming,  conversion
  235. from multicast to unicast,  and application-level filters in  firewalls.   A
  236. translator is neither a synchronization nor a content source.
  237.  
  238. A s_y_n_c_h_r_o_n_i_z_a_t_i_o_n_ u_n_i_t_ consists  of one or  more packets that,  as a  group,
  239. share a common fixed  delay between generation and  playout of each part  of
  240. the group, or can only be scheduled as a whole.  The delay may change at the
  241. beginning of such a synchronization unit.   The most common  synchronization
  242. units are talkspurts for voice and frames for video transmission.
  243.  
  244.  
  245.  
  246. 2.2 RTP Header Fields
  247.  
  248.  
  249. The header fields have the following meaning:
  250.  
  251.  
  252. protocol version: 2 bits
  253.     Defines  the protocol  version.    The version  number of  the  protocol
  254.     defined in this draft is one.
  255.  
  256. flow: 6 bits
  257.     The  value of  the  field is  the  flow  identifier, one  of  the  items
  258.     used by the  receiver for demultiplexing.   A synchronization source  is
  259.     identified by the receiver  as the unique combination of network  source
  260.     address, flow value, and the synchronization source option, if present.
  261.  
  262. option present bit (P): 1 bit
  263.     This flag has a value of one if the fixed RTP header is followed  by one
  264.     or more options.
  265.  
  266. end-of-synchronization-unit (S): 1 bit
  267.     This flag has  a value of  one in the last  packet of a  synchronization
  268.     unit, a value of zero otherwise.
  269.  
  270. format: 6 bits
  271.     The  'format' field  forms  an index  into  a table  defined  through  a
  272.     conference announcement  protocol (to  be specified),  RTCP messages,  a
  273.     conference server or  some other out-of-band means.   If no mapping  has
  274.     been defined  in this  manner, a  standard mapping is  specified by  the
  275.     companion profile document, RFC TBD. RFC 1340, Assigned Numbers,  or its
  276.     successor, is to be used.
  277.  
  278. sequence number: 16 bits
  279.     The sequence  number counts  RTP protocol  data  units (packets).    The
  280.     sequence number increments by one  for each packet sent.  [The  sequence
  281.     number may  be used by the  receiver to detect  packet loss, to  restore
  282.  
  283. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 5]
  284.  
  285.  
  286. INTERNET-DRAFT                        RTP                        May 6, 1993
  287.  
  288.     packet sequence and to identify packets to the application.]
  289.  
  290. timestamp: 32 bits
  291.     The timestamp reflects the  wallclock time when the RPDU was  generated.
  292.     The timestamp consists of the middle 32 bits of a 64-bit  NTP timestamp,
  293.     as defined in RFC 1305  [4].  Note that several consecutive packets  may
  294.     have equal timestamps.
  295.  
  296.     The  timestamp of  the first  packet(s)  within a  synchronization  unit
  297.     is expected  to closely  reflect the actual  sampling instant,  measured
  298.     by the  local system  clock.    It is  not expected  that the  timestamp
  299.     of the  beginning of  every synchronization  unit  is based  on a  local
  300.     synchronized system  clock.   However,  the local clock  should be  used
  301.     frequently enough so that clock drift between synchronized  system clock
  302.     and sampling clock can be  compensated for gradually.  The local  system
  303.     clock should be  controlled by a  time synchronization protocol such  as
  304.     NTP if such  a service is available.   Within one synchronization  unit,
  305.     it may be appropriate to compute timestamps based on the  logical timing
  306.     relationships between the packets.  For audio samples, for  example, the
  307.     nominal sampling interval  may be used.   If the clock quality field  of
  308.     the CDES  option does  not indicate otherwise,  it is  assumed that  the
  309.     timestamp at the beginning  of a synchronization unit is derived from  a
  310.     synchronized system clock.  However, it is allowable to  operate without
  311.     synchronized time on those  systems where it is not available, unless  a
  312.     profile or session protocol requires otherwise.
  313.  
  314.  
  315.  
  316.  0                   1                   2                   3
  317.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  318. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  319. |Ver|   flow    |P|S|  format   |       sequence number         |
  320. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  321. |     timestamp (seconds)       |     timestamp (fraction)      |
  322. +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  323. | options ...                                                   |
  324. +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  325.  
  326.  
  327.                         Figure 1:  RTP header format
  328.  
  329. The packet  header is  followed by  options,  if any,  and the  media  data.
  330. Optional fields are summarized below.   Unless otherwise noted, each  option
  331. may appear only  once per packet.   Each  packet may contain  any number  of
  332. options.
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 6]
  342.  
  343.  
  344. INTERNET-DRAFT                        RTP                        May 6, 1993
  345.  
  346. CSRC 0   Content source identifiers.  The content source option is  inserted
  347.         only by bridges and identifies  all sources that contributed to  the
  348.         packet.   For example,  for audio  packets, all  sources are  listed
  349.         that were mixed  together to  create this  packet, allowing  correct
  350.         talker indication at  the receiver.   Each CSRC  option may  contain
  351.         one or more  content source  identifiers, each  16 bits long.    The
  352.         identifier values must  be unique for  all content sources  received
  353.         through a particular synchronization source (bridge) on a particular
  354.         conference (destination address and port); the value of binary  zero
  355.         is reserved and may not be used.   If the number of content  sources
  356.         is even, the two octets needed to pad the list to a multiple of four
  357.         octets are set to zero.   There should only be a single CSRC  option
  358.         within a packet.  If no  CSRC option is present, the content  source
  359.         is assumed to have a value of  zero.  CSRC options are not  modified
  360.         by RTP-level translators.
  361.  
  362.  
  363.          0                   1                   2                   3
  364.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  365.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  366.         |F|    CSRC     |    length     | content source identifier    ...
  367.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  368.  
  369. SSRC 1   Synchronization source  identifier.     The  SSRC  option  is  only
  370.         inserted by  RTP-level translators;  the  translator must  assign  a
  371.         unique identifier  for each  synchronization  source from  which  it
  372.         receives packets for  a particular  conference (destination  address
  373.         and port).    The  value zero  is reserved  and  must not  be  used.
  374.         If no  SSRC option  is present,  the network  source is  assumed  to
  375.         indicate the synchronization source.  There must be no more than one
  376.         SSRC identifier per packet; thus,  a translator must remap the  SSRC
  377.         identifier of an  incoming packet into  a new,  locally unique  SSRC
  378.         identifier.
  379.  
  380.  
  381.          0                   1                   2                   3
  382.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  383.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  384.         |F|    SSRC     | length = 1    | identifier                    |
  385.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  386.  
  387. BOP 2   (beginning of playout unit)  16-bit sequence number designating  the
  388.         first packet within the current playout unit.
  389.  
  390.  
  391.          0                   1                   2                   3
  392.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  393.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  394.         |F|     BOP     | length = 1    | sequence number               |
  395.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  396.  
  397.  
  398.  
  399. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 7]
  400.  
  401.  
  402. INTERNET-DRAFT                        RTP                        May 6, 1993
  403.  
  404. 3 Reverse Control
  405.  
  406.  
  407. This section describes  a means  for the receiver  of RTP  protocol data  to
  408. signal back to the  sender or a  third party.   Reverse control packets  are
  409. sent to the destination specified  by the sender of  the data using the  RNA
  410. and RTA options.    Use of  reverse control packets  is optional.    Reverse
  411. control packets have the format  shown below.  The  packet is preceded by  a
  412. 32-bit packet length  field if and  only if the  underlying transport  layer
  413. does not support framing.   The packet length  field contains the number  of
  414. octets within the packet, n_o_t_ including the packet length field itself.  The
  415. flow index is that of the flow to which this reverse control is a  response.
  416. Reverse control packets are only sent to the synchronization source.  It  is
  417. the responsibility of the RTP-level bridge to convey information back to the
  418. content sources, if necessary.
  419.  
  420.  
  421.  
  422.  0                   1                   2                   3
  423.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  424. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  425. |       0       |       0       |       0       |  flow index   |
  426. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  427. | reverse-control options (variable length) ...                 |
  428. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  429.  
  430. The following options may be used within reverse control packets:
  431.  
  432.  
  433. QOS 64   Quality of service  measurement.   The option  contains the  number
  434.         of packets received (16  bits), the number  of packets expected  (16
  435.         bits), the minimum delay, the  maximum delay and the average  delay.
  436.         The delay measures are encoded as 16/16 NTP timestamps, that is,  16
  437.         bits encode the  number and seconds  and 16 bits  the fraction of  a
  438.         second.  [The timestamp format is  identical to the one used in  the
  439.         fixed RTP header.]
  440.  
  441.  
  442.           0                   1                   2                   3
  443.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  444.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  445.          |F|     QOS     | length = 5    |            MBZ                |
  446.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  447.          | packets received              | sequence number range         |
  448.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  449.          | minimum delay (seconds)       | minimum delay (fraction)      |
  450.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  451.          | maximum delay (seconds)       | maximum delay (fraction)      |
  452.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  453.          | average delay (seconds)       | average delay (fraction)      |
  454.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  455.  
  456.  
  457. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 8]
  458.  
  459.  
  460. INTERNET-DRAFT                        RTP                        May 6, 1993
  461.  
  462. RAD 65   Reverse application data.    The data  contained in  the option  is
  463.         directly passed to the application, without interpretation by RTP.
  464.  
  465.  
  466.           0                   1                   2                   3
  467.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  468.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  469.          |F|    RAD      |    length     | reverse application data      |
  470.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  471.         ...                                                             ...
  472.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  473.  
  474.  
  475.  
  476. 4 Real Time Control Protocol --- RTCP
  477.  
  478.  
  479. The real-time control protocol  (RTCP) conveys minimal out-of-band  advisory
  480. information during a conference.  It provides support for loosely controlled
  481. conferences, i.e.,  where  participants enter  and leave  without  admission
  482. control and parameter negotiation.   The services provided by RTCP  services
  483. enhance RTP, but an end system does  not have to implement RTCP features  to
  484. participate in conferences(1) .  RTCP  does not aim to provide the  services
  485. of a conference control protocol and  does not provide some of the  services
  486. desirable for two-party conversations.  If a conference control protocol  is
  487. in use, the  services of RTCP should  not be required.   (Note:   as of  the
  488. writing of this document, a conference  or session control protocol has  not
  489. been specified within the Internet.)
  490.  
  491. Unless otherwise  noted,  control  information is  carried  periodically  as
  492. options within RPDUs.    In the absence  of media  data, packets  containing
  493. only RTCP options are sent periodically to the same multicast group as  data
  494. packets, using the same time-to-live value.  Note that RTCP options could be
  495. sent in separate packets even when there is data to send; however, the  RTCP
  496. packets would consume sequence  numbers and make detection  of lost data  at
  497. the receiver more difficult.  The period should be varied randomly to  avoid
  498. synchronization of all sources and its mean should increase with the  number
  499. of participants in the conference  to limit the overall  network load.   The
  500. length of the period determines, for example, how long a receiver joining  a
  501. conference has to wait in the worst  case until it can identify the  source.
  502. An initial period varying randomly between 3 and 10 seconds is  recommended.
  503. A receiver may remove  a site that it  has not been heard  from for a  given
  504. time-out period  from its  list of  active sites;  the  time-out period  may
  505. depend on the number of sites  or the observed average interarrival time  of
  506. RTCP messages.  Note that not every periodic message has to contain all RTCP
  507. options; for example,  the MAIL part  within the SDES  option might only  be
  508.  
  509. ------------------------------
  510.  1. There  is one  exception to  that rule:   if  an application  sends  FMT
  511. options, the receiver has to decode these in order to properly interpret the
  512. RTP payload.
  513.  
  514.  
  515. H. Schulzrinne/S. Casner              Expires 10/01/93              [Page 9]
  516.  
  517.  
  518. INTERNET-DRAFT                        RTP                        May 6, 1993
  519.  
  520. sent every few messages.
  521.  
  522. The item types are defined below:
  523.  
  524.  
  525.  
  526. 4.1 Forward Control Options
  527.  
  528.  
  529. The following options are sent in the same direction as the data stream.
  530.  
  531.  
  532. FMT 32   Format description.
  533.  
  534.  
  535.         format:  6 bits
  536.             The 'format' field designates the index value from  the 'format'
  537.             fixed header field, with values ranging from 0 to 63.
  538.  
  539.         Clock quality:  8 bits
  540.             Provides an  indication as  to the  sender-perceived quality  of
  541.             the timestamps  in the  RTP header.   The  octet is  interpreted
  542.             as a quantity indicating  the maximum dispersion to a root  time
  543.             server measured  in fractions  of a  second and  expressed as  a
  544.             power of two.
  545.  
  546.             If a source  is known to be  synchronized to standard time,  but
  547.             with an  unknown dispersion, or the  dispersion is greater  than
  548.             TBD, the  value TBD  is used.    If the  clock is  based on  the
  549.             nominal sample rate of the source, a value of TBD is used.
  550.  
  551.             The clock quality indication can be used to judge how  the delay
  552.             measurements reported by the  QOS option can be interpreted  (as
  553.             absolute delay or only as  delay variation).  It is also  useful
  554.             for determining  to what extent  several sources with  different
  555.             clocks can be synchronized.
  556.  
  557.         Format-dependent data:  variable
  558.             Format-dependent data  may or may  not appear in  a FMT  option.
  559.             It is passed to the next layer and not interpreted by RTP.
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 10]
  574.  
  575.  
  576. INTERNET-DRAFT                        RTP                        May 6, 1993
  577.  
  578.         A FMT  mapping  changes  the interpretation  of  a  given  'content'
  579.         value starting at  the packet containing  the FMT option.   The  new
  580.         interpretation applies  only  to packets  from  the  synchronization
  581.         source of this packet.   A sender  should refrain from changing  the
  582.         content type and flow index of  a mapping defined by external  means
  583.         such as a conference  registry, conference announcement protocol  or
  584.         otherwise agreed-upon  mapping.   Dynamic  changes to  these  values
  585.         may result  in misinterpretation  of RTP  payload if  the  packet(s)
  586.         containing the FMT option are lost.
  587.  
  588.  
  589.           0                   1                   2                   3
  590.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  591.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  592.          |F|     FMT     |    length     |0|0|  format   | clock quality |
  593.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  594.          |  format-dependent data                                       ...
  595.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  596.  
  597. SDES 33   This option provides a mapping between a numeric source identifier
  598.         and one or more  identifying attributes.   [Several attributes  were
  599.         combined into one option to avoid multiple mappings from identifiers
  600.         to the receiver site data structure.]  For those applications  where
  601.         the size of  a multipart SDES  option would be  a concern,  multiple
  602.         SDES options may be formed with subsets  of the parts to be sent  in
  603.         separate packets.  An end system always uses an identifier value  of
  604.         zero.   A bridge uses  the content source  identifiers used in  CSRC
  605.         options to identify contributors,  and a value  of zero to  identify
  606.         itself.  Translators do not modify or insert SDES options.  The  end
  607.         system performs the  same mapping  it uses to  identify the  content
  608.         sources (that is, the combination of network source, synchronization
  609.         source and the source number within this SDES option) to identify  a
  610.         particular source.
  611.  
  612.         Currently, the following items  are defined.   Each has a  structure
  613.         similar to that  of RTCP  and RTP  options,  that is,  a type  field
  614.         followed by a length field  (measured in multiples of four  octets).
  615.         No final bit is needed since the overall length is known.
  616.  
  617.         The class  identifier of  the informational  items within  the  SDES
  618.         option is  identical  to the  CLASS  value in  the  resource  record
  619.         (RR) in  the  Domain Name  Service  protocol (DNS)  [RFC  1034,  RFC
  620.         1035] [5,6] and may be found in the current version of the Assigned
  621.         Numbers RFC  issued  by  the Internet  Assigned  Numbers  Authority.
  622.         Additional values  that  are  reserved are  used  for  SDES-specific
  623.         identifiers.
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 11]
  632.  
  633.  
  634. INTERNET-DRAFT                        RTP                        May 6, 1993
  635.  
  636.               name  class   description
  637.               USER  0       user and host identifier,
  638.                             e.g., ``doe@sleepy.megacorp.com'' or
  639.                             ``sleepy.megacorp.com''
  640.               MAIL  3       user's electronic mail address
  641.                             e.g., ``John.Doe@megacorp.com''
  642.               TEXT  65535   text describing the source,
  643.                             e.g.,``John Doe, Bit Recycler, Megacorp''
  644.               ADDR  1       IPv4 address of source
  645.                     2-65534 other address formats
  646.  
  647.  
  648.  
  649.         Class value 4  is currently assigned  to historical network  address
  650.         types (HESSIOD)  and thus  safe for  private SDES  use.   Items  are
  651.         padded with zero to the next multiple of four octets.  The USER item
  652.         must have the format  ``user@host'' or ``host'',  where ``host''  is
  653.         the fully qualified domain name of the host where the real-time data
  654.         originates from, formatted according to  the rules specified in  RFC
  655.         1035.  The latter form may be used if a user name is  not available,
  656.         for example on  single-user systems.   The  user name  should be  in
  657.         a form that  a program  such as  ``finger'' or  ``talk'' could  use,
  658.         i.e., it typically is the login  name rather than the ``real  life''
  659.         name.  Note that the host  name is not necessarily identical to  the
  660.         electronic mail address of the participant.  The latter is  provided
  661.         through the MAIL option.  The USER item is intended to be parsed  by
  662.         an application program.
  663.  
  664.  
  665.           0                   1                   2                   3
  666.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  667.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  668.          |F|     SDES    |    length     |       source identifier       |
  669.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  670.  
  671.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  672.          |            class = 0          |    length     | text         ...
  673.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  674.          | ... describing the source ...                                ...
  675.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  676.  
  677.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  678.          |        class = 0xFFFF         |    length     | user and     ...
  679.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  680.          | domain name of source                                        ...
  681.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  682.  
  683.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  684.          |          class = 1            |   length      |       0       |
  685.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  686.          |                          IPv4 address                         |
  687.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  688.  
  689. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 12]
  690.  
  691.  
  692. INTERNET-DRAFT                        RTP                        May 6, 1993
  693.  
  694. RNA 36   The RNA  (reverse network  address) indicates  the network  address
  695.         to be used for  sending reverse control data  for the given  content
  696.         type.   The address  type field  contains the  address class,  using
  697.         the DNS-based namespace  described for the  SDES option above.    If
  698.         a host has  several network  addresses (for  example, for  different
  699.         network protocols), the  RNA option is  to be repeated  as often  as
  700.         needed.   The  receiver  then chooses  the address  appropriate  for
  701.         its needs.   The  'interval' field  contains the  number of  seconds
  702.         between QOS packets, expressed  as the exponent of  a power of  two.
  703.         For example,  a value  of  3 means  that the  source would  like  to
  704.         receive quality-of-service reports  every 2 **  3 = 8  seconds.   To
  705.         avoid synchronization between receivers, a receiver should space QOS
  706.         reports randomly between one half and twice the interval  requested.
  707.         The interval is advisory only and an application may choose to  send
  708.         QOS reports at a different frequency.  [This caveat is necessary  as
  709.         keeping track of a different interval for each source may be  unduly
  710.         burdensome.]  A profile may specify a different algorithm.  A  value
  711.         in the 'interval' field of 255  decimal implies that no QOS  packets
  712.         should be sent.
  713.  
  714.  
  715.          0                   1                   2                   3
  716.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  717.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  718.         |F|    RNA      |    length     |    format     |   interval    |
  719.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  720.         |         address class         |       0       |       0       |
  721.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  722.         |                        network-address                       ...
  723.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  724.  
  725.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  726.         |F|    RNA      |  length = 2   |    format     |   interval    |
  727.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  728.         |      address class = 1        |       0       |       0       |
  729.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  730.         |                          IPv4 address                         |
  731.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  732.  
  733. RTA 37   The  RTA  (reverse  transport  address)  indicates  the   transport
  734.         selector (e.g., port number) to be used for sending reverse  control
  735.         data.   The transport protocol  field determines the  interpretation
  736.         of the following octets,  using the IP  Protocol Numbers defined  in
  737.         the current edition of  the Assigned Numbers  RFC. The figure  shows
  738.         the use of  the RTA  option for the  ST-II, TCP  and UDP  protocols.
  739.         [The port numbers are placed so  that the second 32-bit word can  be
  740.         interpreted as the port  number, with  the most-significant bits  as
  741.         zero.]
  742.  
  743.  
  744.          0                   1                   2                   3
  745.  
  746.  
  747. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 13]
  748.  
  749.  
  750. INTERNET-DRAFT                        RTP                        May 6, 1993
  751.  
  752.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  753.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  754.         |F|    RTA      |    length     |    format     | transport pro.|
  755.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  756.         |              transport-address (port number)                 ...
  757.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  758.  
  759.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  760.         |F|    RTA      |  length >= 2  |    format     | protocol = 5  |
  761.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  762.         |       0       |       0       |       0       |   SAP bytes   |
  763.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  764.         |    padding    : ST-II service access point                   ...
  765.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  766.  
  767.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  768.         |F|    RTA      |  length = 2   |    format     | protocol = 6  |
  769.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  770.         |       0       |       0       |        TCP port number        |
  771.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  772.  
  773.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  774.         |F|    RTA      |  length = 2   |    format     | protocol = 17 |
  775.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  776.         |       0       |       0       |        UDP port number        |
  777.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  778.  
  779. BYE 35   The BYE  option  indicates that  a  particular site  is  no  longer
  780.         active.  A bridge sends BYE options with a (non-zero) content source
  781.         value.   An  identifier  value of  zero  indicates that  the  source
  782.         indicated by the  synchronization source (SSRC)  option and  network
  783.         address is no  longer active.   If  a bridge shuts  down, it  should
  784.         first send BYE options for all content sources it handles,  followed
  785.         by a BYE option with an identifier value of zero.  Each RTCP message
  786.         can contain one or  more BYE messages.   [Multiple identifiers in  a
  787.         single BYE option are not  allowed to avoid ambiguities between  the
  788.         special value of zero and any necessary padding.]
  789.  
  790.  
  791.          0                   1                   2                   3
  792.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  793.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  794.         |F|     BYE     | length = 1    | content source identifier     |
  795.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 14]
  806.  
  807.  
  808. INTERNET-DRAFT                        RTP                        May 6, 1993
  809.  
  810. 5 Security Considerations
  811.  
  812.  
  813. RTP suffers from the same security deficiencies as the underlying protocols,
  814. for example,  the  ability of  an impostor  to  fake source  or  destination
  815. network addresses.
  816.  
  817. The usage  of  network  addresses for  identification  within  the  protocol
  818. (SDES  option)  allows  impersonating  another  site.     Impersonation  and
  819. denial-of-service attacks can  be made more  difficult by providing  digital
  820. signatures for all or parts of a  message.  IP multicast provides no  direct
  821. means for a sender to know all the receivers of the data sent.   RTP options
  822. make it easy for all participants in a conference to identify themselves; if
  823. deemed important for a particular  application, it is the responsibility  of
  824. the application writer to  make listening without identification  difficult.
  825. It should be noted, however, that within an internet, privacy of the payload
  826. can generally only be assured by encryption.
  827.  
  828. The TBD  RTP options  described in  Section  2 allow  the provision  of  the
  829. following security services within this layer:  TBD.
  830.  
  831.  
  832.  
  833. 6 RTP over network and transport protocols
  834.  
  835.  
  836. This  section  describes  issues  specific  to  carrying  RTP  packets  over
  837. particular network and  transport protocols.   Unless  otherwise noted,  the
  838. mechanisms apply to both the forward (data) and reverse control directions.
  839.  
  840.  
  841. 6.1 Defaults
  842.  
  843.  
  844. The following rules apply unless superseded by protocol-specific subsections
  845. in this section.
  846.  
  847.  
  848. 6.1.1 Framing
  849.  
  850.  
  851. If RTP protocol data units (RPDU),  in both forward and reverse  directions,
  852. are carried  over underlying  protocols that  provide the  abstraction of  a
  853. continuous bit  stream rather  than messages,  each RPDU  is prefixed  by  a
  854. 32-bit framing field containing the length  of the RPDU measured in  octets,
  855. not including the framing  field itself.   If a RPDU  traverses a path  over
  856. a mixture of  octet-stream and  message-oriented protocols,  each  RTP-level
  857. bridge between these protocols  is responsible for  adding and removing  the
  858. framing field.   A  profile may  determine that framing  is to  be used  for
  859. protocols that do  provide framing in  order to allow  carrying several  RTP
  860. packets in one underlying protocol data unit.  [Carrying several RTP packets
  861.  
  862.  
  863. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 15]
  864.  
  865.  
  866. INTERNET-DRAFT                        RTP                        May 6, 1993
  867.  
  868. in one network  or transport  packet reduces  header overhead  and may  ease
  869. synchronization between different streams.]
  870.  
  871.  
  872. 6.1.2 RTA option
  873.  
  874.  
  875. Port numbers (or equivalent) are by default two octets long.
  876.  
  877.  
  878.  
  879. 6.2 UDP
  880.  
  881.  
  882. The format of the RTA option is shown below.
  883.  
  884.  
  885.  0                   1                   2                   3
  886.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  887. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  888. |F|    RTA      |  length = 2   |    format     | protocol = 17 |
  889. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  890. |       0       |       0       |        UDP port number        |
  891. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  892.  
  893.  
  894. 6.3 TCP
  895.  
  896.  
  897. The format of the RTA option is shown below.
  898.  
  899.  
  900.  0                   1                   2                   3
  901.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  902. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  903. |F|    RTA      |  length = 2   |    format     | protocol = 6  |
  904. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  905. |       0       |       0       |        TCP port number        |
  906. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  907.  
  908.  
  909. 6.4 ST-II
  910.  
  911.  
  912. The next protocol field (``NextPCol'', Section 4.2.2.10 in RFC-1190) is used
  913. to distinguish two encapsulations of RTP over ST-II. The first uses NextPCol
  914. value TBD and directly places the RTP packet  into the ST-II data area.   If
  915. NextPCol value TBD is used,  the RTP header is  preceded by a 32-bit  header
  916. shown below.   The  byte count  determines the number  of bytes  in the  RTP
  917. header and payload to be checksummed.  The 16-bit checksum uses the TCP  and
  918.  
  919.  
  920.  
  921. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 16]
  922.  
  923.  
  924. INTERNET-DRAFT                        RTP                        May 6, 1993
  925.  
  926. UDP checksum algorithm.
  927.  
  928.  
  929.  
  930.   0                   1                   2                   3
  931.   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  932.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  933.  | count of bytes to be checked  |           check sum           |
  934.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  935. ... RTP header ...
  936.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  937.  
  938. The format of the RTA option is shown below.
  939.  
  940.  
  941.  0                   1                   2                   3
  942.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  943. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  944. |F|    RTA      |  length = 2   |    format     | protocol = 5  |
  945. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  946. |       0       |       0       | ST-II service access pt (SAP) |
  947. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  948.  
  949.  
  950. A Implementation Notes
  951.  
  952.  
  953. In this section,  one possible implementation  of the part  of the  receiver
  954. that maps  incoming RTP  packets to  sources  is described.    The  receiver
  955. maintains a list of all  sources, content and synchronization sources  alike
  956. in a  table.   Synchronization  sources  are stored  with a  content  source
  957. value of zero.   When  an RTP  packet arrives, the  receiver determines  its
  958. network source and port (from information returned by the operating system),
  959. synchronization source (SSRC  option) and content  source(s) (CSRC  option).
  960. To locate  the  table  entry containing  timing  information,  mapping  from
  961. content descriptor to actual encoding,  etc., the receiver sets the  content
  962. source to  zero and  locates a  table  entry based  on the  triple  (network
  963. address and port, synchronization source identifier, 0).
  964.  
  965. The receiver identifies  the contributors to  the packet  (for example,  the
  966. speaker who is  heard in  the packet) through  the list  of content  sources
  967. carried in the CSRC option.   To locate the  table entry, it matches on  the
  968. triple (network address and port, synchronization source identifier, content
  969. source).
  970.  
  971. Note that  since  network  addresses  are  only  generated  locally  at  the
  972. receiver, the receiver can choose whatever format seems most appropriate for
  973. matching.  For example, a Berkeley Unix-based system may use struct sockaddr
  974. data types if it expects network sources with non-IP addresses.
  975.  
  976.  
  977.  
  978.  
  979. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 17]
  980.  
  981.  
  982. INTERNET-DRAFT                        RTP                        May 6, 1993
  983.  
  984. Acknowledgments
  985.  
  986.  
  987. This draft  is based  on discussion  within the  IETF audio-video  transport
  988. working group  chaired by  Stephen Casner.    The current  protocol has  its
  989. origins in the Network Voice Protocol  and the Packet Video Protocol  (Danny
  990. Cohen and Randy Cole) and the protocol implemented by the 'vat'  application
  991. (Van Jacobson and Steve McCanne).
  992.  
  993.  
  994.  
  995. B Addresses of Authors
  996.  
  997.  
  998. Stephen Casner
  999. USC/Information Sciences Institute
  1000. 4676 Admiralty Way
  1001. Marina del Rey, CA 90292-6695
  1002. telephone:  +1 310 822 1511 (extension 153)
  1003. electronic mail:  casner@isi.edu
  1004.  
  1005.  
  1006. Henning Schulzrinne
  1007. AT&T Bell Laboratories
  1008. MH 2A244
  1009. 600 Mountain Avenue
  1010. Murray Hill, NJ 07974
  1011. telephone:  +1 908 582 2262
  1012. electronic mail:  hgs@research.att.com
  1013.  
  1014.  
  1015.  
  1016. References
  1017.  
  1018.  
  1019. [1] J.  Postel, ``Internet  protocol,'' Network  Working  Group Request  for
  1020.     Comments RFC 791, Information Sciences Institute, Sept. 1981.
  1021.  
  1022. [2] International   Standards  Organization,   ``ISO/IEC  DIS   10646-1:1993
  1023.     information technology  -- universal multiple-octet coded character  set
  1024.     (UCS) -- part I: Architecture and basic multilingual plane,'' 1993.
  1025.  
  1026. [3] The  Unicode Consortium,  T_h_e_  U_n_i_c_o_d_e_  S_t_a_n_d_a_r_d_. New  York,  New  York:
  1027.     Addison-Wesley, 1991.
  1028.  
  1029. [4] D.  L. Mills,  ``Network  time protocol  (version 3)  --  specification,
  1030.     implementation  and  analysis,''  Network  Working   Group  Request  for
  1031.     Comments RFC 1305, University of Delaware, Mar. 1992.
  1032.  
  1033. [5] P.  Mockapetris, ``Domain names  -- concepts  and facilities,''  Network
  1034.     Working Group Request for Comments RFC 1034, ISI, Nov. 1987.
  1035.  
  1036.  
  1037. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 18]
  1038.  
  1039.  
  1040. INTERNET-DRAFT                        RTP                        May 6, 1993
  1041.  
  1042. [6] P. Mockapetris,  ``Domain names  -- implementation and  specification,''
  1043.     Network Working Group Request for Comments RFC 1035, ISI, Nov. 1987.
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095. H. Schulzrinne/S. Casner             Expires 10/01/93              [Page 19]
  1096.